1. Field of the Invention
The present invention relates to communications network equipment design, including Multi-Service Provisioning Platform (MSPP) systems with Ethernet over SONET functions. More specifically, the present invention provides a simple, efficient, and scalable method for building an Aggregation/Grooming Engine (AGE) for processing packet flows. Further, the present invention involves an Ethernet over SONET system that employs the AGE technique.
2. Description of the Prior Art
In the field of communications, SONET and SDH are a set of related standards for synchronous data transmission over fiber optic networks. SONET is short for Synchronous Optical NETwork and SDH is an acronym for Synchronous Digital Hierarchy. SONET is the United States version of the standard published by the American National Standards Institute (ANSI). SDH is the international version of the standard published by the International Telecommunications Union (ITU).
Ethernet over SONET/SDH (EOS) technology came about in the recent years as a popular way of adding new data services such as Ethernet data transport SONET/SDH network that is originally designed to carry TDM (time division multiplexing) services such as telephone services. Ethernet being the ubiquitous interface in the Enterprise network is regarded as the most convenient customer interface for delivering data service. SONET/SDH is the most broadly deployed technology in the WAN or MAN infrastructures all over the world. Ethernet Over SONET is a powerful combination that takes advantage of the existing network infrastructure and the broad user base of Ethernet as a data communication technology.
Typically, the adaptation function to mapping Ethernet frames into a SONET/SDH bit stream is carried out at the edge of the network in a category of network equipment called Multi-Service Provisioning Platform (MSPP) device. The MSPP typically has at least two types of the interfaces: SONET/SDH interfaces, and Ethernet interfaces. The SONET/SDH line and tributary interfaces provide connection to the MAN or WAN SONET/SDH rings or TDM services nodes. The Ethernet ports are either connected to customers directly or L2/L3 data switches for implementing L2/L3 data switch-overlay network. In the overlay network, the SONET network with MSPP devices at the edge provides physical layer transport among the L2/L3 switches. The physical realization of the transport network is therefore invisible to the switches as they regard the transport as a virtual point-to-point media. In this overlay network model, the complexity of the SONET/SDH transport network is isolated from the complexity of the L2/L3 switching/routing network. The different network functions at different layers can be realized in different network equipment and are managed separately.
The basic concept of Ethernet over SONET network is shown in prior art FIG. 1. There are a number of ways of implementing Ethernet over SONET services within the MSPP devices with the assist of external L2/L3 switches. Independent of the processing function at the EOS adaptation layer and above, the primary characteristics of EOS technology remains unchanged. That is to use Ethernet as the data service user network interface and network-to-network interface, and to use SONET/SDH as the underlying transport layer. As in any other data service network, the concept of grooming and aggregation is applicable to a multi-service network based on SONET/SDH and EOS technologies. For purposes of the present discussion, the focus is with the grooming and aggregation issues in multi-service networks.
There are a number of ways of implementing Ethernet over SONET function in the MSPP nodes. Most implementations utilize a number of emerging networking standards including: ITU-T G.7041, Generic Framing Procedure (GFP); ITU-T G.7042, Link capacity adjustment scheme (LCAS) for virtual concatenated signals; ITU-T G.707, “Network Node Interface for the Synchronous Digital Hierarchy”, Helsinki, March 1996; T1X1.5/2000-192, Supplement to T1.105.02-2000, “SONET Payload Mappings (inclusion of Virtual Concatenation)”, 2000; T1X1.5/2000-193, Supplement to T1.105-2000, “SONET Basic Description including Multiplex Structure Rates and Formats (inclusion of Virtual Concatenation)”, 2000; IETF RFC 1661, the Point to Point Protocol; ITU-T X.85 IP over SDH using LAPS; and ITU-T X.86, Ethernet over SDH using LAPS. These standard protocols provide the basic building blocks for implementing EOS systems.
The Virtual Concatenation protocol provides ways of concatenating a number of SONET/SDH time slots to form transport pipes of flexible bandwidth. Virtual concatenation can be done both at STS/STM level (High Order), or Virtual Tributary Level (Low Order). The High Order Virtual Concatenation mapping and Low Order Virtual Concatenation mapping provides virtual concatenation function at different bandwidth granularities.
LCAS provides a mechanism for dynamically adjusting the size of a Virtually Concatenated channel (virtual concatenation group). This allows TDM services to be more flexibility for handling dynamic bandwidth demands. LCAS relies on the network NMS/EMS to provision the bandwidth change. LCAS protocol coordinates the operations of the two end points of the Virtual concatenation group to ensure the channel size adjustment to be hitless.
GFP, X.85, X.86, and PPP are various ways of adapting and mapping Ethernet frames (packets) to SONET/SDH bit stream. For example, GFP defines a generic framing procedure to encapsulate variable length payload of various client signals for subsequent transport over SDH and OTN networks as defined in ITU-T G.707 and G.709. The details about encapsulation, frame delineation, and communicating mechanism for control-information differ from one protocol to the other. However, the basic adaptation function between Ethernet frames and SONET/SDH transport format is common.
These well-known protocols provide the basis for most, if not all, Ethernet over SONET/SDH implementation. The current EOS systems can be broadly divided into the two categories, which are considered as the prior art references: Layer 1 (L1) EOS transport systems and Layer 2/3 (L2/3) EOS switch systems.
The L1 EOS transport systems endeavour to provide point-to-point Ethernet private line services over SONET/SDH transport infrastructure. These systems use Ethernet ports as the private line demarcation point between the client and the network. In other words, the hand off point between the network and the client and the service level agreement is defined over the Ethernet media between a client device and the Ethernet port service provider MSPP device. To provide an EOS private line between two points (A and B) in the network would required MSPP devices at both end points: MSPP_A and MSPP_B. MSPP_A would accept the client Ethernet data flow over the assigned Ethernet port on MSPP_A for this client, and adapt the Ethernet flows (frames) into SONET/SDH Virtual concatenation or contiguous concatenation group. The SONET/SDH transport network will deliver the constituent time slots (channels) of the concatenation group over common or diverse paths to end point B. The MSPP device at point B would take the constituent channels (paths) and do the merging, alignment, and reverse mapping from the SONET/SDH data format to recover the Ethernet frame format. By configuring the number of time slots to the concatenation group, the service provider can control the transport bandwidth of the EOS private line.
FIG. 2 shows the block diagram of a prior art device that implements a typical L1 Ethernet over SONET Transport System in a single IC device. Such device provides mapping function from Gigabit Ethernet ports to SONET virtual concatenation groups using GFP, X.86, and SONET virtual concatenation technologies. The system can be conceptually divided into the following functional blocks:                a. Ethernet MAC and buffer (implements 802.3 function)        b. Frame Encapsulation/Decapsulation Engine (implements GFP, X.86 etc)        c. Transmit/Receive Virtual Concatenation Processor (implements SONET/SDH Virtual Concatenation and Contiguous Concatenation mapping function)        d. SONET protocol processor (provides the interface to SONET/SDH network)        
The L1 Ethernet over SONET Transport Systems are well suited for provided point to point Ethernet private line service between two client sites. However, this technique becomes inefficient when a common network node need to deal with many leased lines (point to multi-point applications). One example of such a scenario is an enterprise headquarters' need to have a number of leased lines to the many branch offices. Another example is a service provider point of presence (POP) needing to deal with many customer traffic flows carried by individual leased lines from different customer sites. The inefficiency arises as the L1 Ethernet over SONET Transport Systems can only deal with a single client EOS data flow on each Ethernet physical interface. In the case of the service provider POP that has N client flows to deal with, the MSPP device facing the POP has to assign as many (N) Ethernet over SONET ports of the MSPP as there are number of customer flows. Also, the N client flows will consume N ports on the POP equipment (switch or router) as these flows are delivered over individual Ethernet physical ports. The drawbacks of this approach for point to multi-point applications include:                a. Poor scalability: The number of flows that an MSPP or POP switch can service is limited by the number of physical Ethernet interfaces.        b. Poor bandwidth efficiency: The EOS private line client flows have much lower rate than the physical port bandwidth. When each flow is delivered using a physical Ethernet port, the port bandwidth is underutilized.        c. High equipment cost: The low efficiency of the ports on MSPP and switches means to service the same total traffic load, the number of ports on equipment need to be higher. This results in higher total equipment cost.        d. Inflexibility and higher maintenance cost: Each client flow requires one physical cabling between the MSPP device and the adjacent switch/router.        
It is possible to provide a more “efficient” solution by performing switching at L2 or L3 to aggregate and/or locally switch traffic. The L2/L3 Ethernet over SONET/SDH Switch systems combines the function of Ethernet over SONET mapping and L2/L3 Ethernet switching into the MSPP system. FIG. 3 shows a prior art L2/L3 Ethernet over SONET/SDH Switch System Block Diagram. The system contains the functional blocks for a L1 EOS system such as Ethernet MAC, encapsulation, Virtual concatenation processing, and SONET/SDH overhead termination required. Additionally, the L2/L3 EOS system also includes Ethernet L2/L3 switching function. The L2/l3 EOS system combines the function of traditional SONET/SDH transport system and L2/L3 Ethernet switch or IP router function into a common hardware platform. The L2/L3 EOS systems can be used to build an overlay L2/L3 network on top of SONET/SDH network as shown in FIG. 4.
Substantial hardware saving may be achieved because the single EOS system can deliver the function of two types of traditional hardware systems. However, adding L2/L3 switching function into a MSPP system has a large impact on the architecture of the MSPP system and the design of the overall network. In order to provide the traditional L2/L3 switching/routing function, the MSPP now have to incorporate the L2 and L3 control plane function, namely the 802.1D bridging protocols and the routing protocols such as OSPF and BGP. This adds significant complexity to the MSPP system. Also, adding complete L2/L3 switch functions to the MSPP would required the MSPP system to incorporate a packet switch fabric in additional to the TDM switching fabric. That adds a large cost burden on the MSPP hardware.
Often, an MSPP system designer chooses to implement the L2/L3 switching function on the EOS data line-card to avoid the cost burden of the additional full-scale packet switch fabric or a combined switch fabric that can deal with both TDM cross-connect function as well as packet switching function. The consequence is MSPP systems logically become a distributed L2/L3 switch connected by TDM fabric. Each line-card have to be treated as an independent switch associated with its own bridging and routing protocol instantiation. Also, the switching function is limited to be among the ports on the line-card instead of providing full local switching capability among all the ports on the MSPP system. These limitations further complicate system and network design and network administration overhead.
When the MSPP devices are running L2/L3 bridging protocols, there is an issue of interaction between the MSPP bridges/routers interact with the client switches/routers. For example, the MSPP 802.1D protocol engine automatically learns the MAC addresses and topology in the client's enterprise network and makes forwarding decisions according to the spanning tree and forwarding database. This may cause complex network management, security, and scalability issues, as the service provider equipment is now participating in the bridging/routing domain of the Enterprise network. These issues are undesirable either from the Enterprise network administration perspective or from the service provider's perspective as neither group has full control over the network devices involved.
Another challenge of L2/L3 EOS systems is in network deployment difficulties. The bridging/routing protocols running on the L2/L3 EOS systems need to communicate with equal peer nodes to exchange bridging and routing information. For example, to deploy an overlay L2 network requires all the L2 edge nodes on the overlay network to have the same L2 capabilities to allow 802.1D protocol to function properly. That forces all MSPP nodes in the network to adopt the L2/L3 EOS system. This forklift deployment approach may be suitable for new network deployment, but is very costly for incremental network upgrades. The L2/L3 EOS system nodes cannot inter-operate with L1 EOS system nodes because the L1 nodes lack the capability of L2/L3 bridging/routing protocols.
Yet another challenge in L2/L3 EOS system is the difficulty in providing Quality of Service (QOS) guarantees for the data services at L2 and L3. Many of the business data services are connection oriented (private line like). These flow-based services require the service provider to guarantee the service qualities as specified in Service Level Agreements (SLA). The SLA often specifies traffic profile characteristics such as minimal bandwidth, maximum delay, packet loss ratio, etc. The L1 EOS technology can deliver QOS characteristics relatively easily by provisioning SONET/SDH transport bandwidth to according to the SLA. Due to the connectionless nature of Ethernet and IP protocols, it is much more difficult to provide the same QOS guarantees at Ethernet or IP layer. Although technologies such as MPLS, Diffserv, IntServ, and 802.1p have been introduced to improve the L2/L3 QOS. The cost and complexity of implementing such higher layer QOS capabilities is often higher than L1 EOS systems. Accordingly, while an L1 architecture does not invalidate L2/L3 service models, it is not clear that the transport providers will benefit from implementing L2/L3 service models that comes with full-up L2/L3 “layering”.
What is needed therefore is a flexible and efficient mapping procedure capable of mapping between Ethernet frame formats and SONET transport channels.